無秩序なif-elseは死ねば良いのに

概要

ポエムです。

無秩序なif-elseは死ねば良いのにと思う理由

if-else書かなきゃいけないとき、それが

if {} に対して排他的な要素をelse {} に書かなきゃいけないんだが、

if situation {

route A

} else {

route B

}

なんっつーーーか単純に負けた感じするんだよな。

状況を読み切れてないというか、打算的ではない感じがする。

考えるのサボったんじゃねえのみたいな。

変更可能性を高く保ちたい

自分が感じるif-elseの最高に嫌いなところは、

if-elseなコードは将来の変更可能性を著しく損なう ということにある気がした。

あとで変更加えるときに

「これはelseにくる場合の可能性をどれだけ考慮してるか」

っていうのを「変更したくなったその都度、コードから」見ないといけない。

これはとてもとても面倒臭い。

で、読むのが面倒くさい = 取りうる値が自明であることが読みにくいコード = 変更可能性が低いコード、

という式が自分の中で成立してしまう。

状態を持ったコードなんかもそうなんだけど、

状態を持たないコードであっても、値の範囲がパッと読めないだけで苦しくなる。

で、これをどう改善しようかみたいに考える。

例を殴って直そう

例えば

string a = GetResult

if a == “something” {

route A

} else {

route B

}

みたいなコードがあったとして、elseに来る可能性があるaの中身は、実際なんだろう。

スッゲー膨大になるよな。

route Bにくるときのパターンは “somethingではない” くらいの情報しか無い。

これを今から殴りたい。

自明化

できればif文に乗ってくる要素がcontextとして一列に並べられるような設計にして、

かつそれらを選択肢が網羅していることが自明であると嬉しい。

まずは取り得る選択肢の幅そのものを小さくできないものか。

enum a = GetResult

if a == enum .enumA {

route A

} else {

route B

ここにくるのは少なくともenumに定義された何かっぽい気がする

}

このへんがif-elseの限界で、行き詰まる。

で、じゃあif捨てよーぜって感じで、switchとかmatchとか。

この時点で選べない言語が出てくるが気にしない。

enum a = GetResult

switch a {

case enum.enumA:

route A

break

default:

route B

break

}

さらに、取り得る選択肢がexhaustiveな要素だと自動的に明示できるようだと素晴らしい。

けどこれは出来る言語見たこと無い。

enum a = GetResult

switch a {

case enum.enumA:

route A

break

default: <- not exhausted yet. enum.enumB, enum.enumC is not used in this block

route B

break

}

default(wildcard)があるにも関わらず、ピンクな部分のエラーを出せる言語を自分は知らない。

っていうかshould exhaustなenumとかがあればそういうのできる言語ありそうな気がする。

ここから先はスピリチュアルな変更を伴う感じの調整が出来る。

そもそもenumの要素がすべて現れ、かつ使われるような要素になるように

「考え直す」とか。

飽きたのでここまでにする。

ぶっちゃけコンパイラが賢い言語でswitchとかmatchが使えると平滑にする術が増えるし

幸せになれるなって感じ。

転じてifの価値は低い。

オチは無いです。